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METHOD FOR USING AUTOMATED TELLER MACHINE SWITCH 
SETTLEMENT FOR PROCESSING TRANSACTIONS 



10 

RELATED APPLICATION 

This application is based on and claims priority to U.S. 
Provisional Patent Applications Nos. 60/132,305, filed May 3, 1999, and 
60/150,725, filed August 25, 1999, the entire disclosures of which are hereby 
1 5 incorporated by reference. 

FIELD OF THE INVENTION 

The present invention generally relates to methods for 
processing electronic payments purchases made over the Internet and more 
2 0 particularly to a method by which a consumer pushes a payment to an Internet 

merchant. 



BACKGROUND OF THE INVENTION 

Presently, there are several methods by which a consumer can 

2 5 electronically pay for purchases made on the Internet, such as credit cards, off- 

line debit cards, online debit cards, digital cash, and smart cards. Each of 
these methods has its own advantages and disadvantages. An off-line debit 
card uses the traditional credit card system for clearing the payment but no 
Personal Identification Number (PIN) is required. The use of an on-line debit 

3 0 card requires that the consumer supply his or her PIN, and the amount of the 

purchase is debited from the consumer's account instantaneously. One 
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disadvantage with both the on and off-line debit cards, from a consumer's 
point of view, is the inability to reverse or repudiate the transaction. In 
contrast, by use of a credit card, the consumer at a later date can reverse the 
transaction (e.g., if the purchased goods are never shipped to the consumer). 

It is predicted that credit cards will be the dominant on-line point 
of sale (POS) payment choice for at least the next five years. While new 
Internet payment mechanisms have been rapidly emerging, consumers and 
merchants have been happily conducting a growing volume of commerce 
using basic credit card functionality. None of the emerging efforts to date 
have gotten more than a toehold in the market place and momentum continues 
to build in favor of credit cards. 

Automated Clearing House (ACH) payments have begun to be 
used with respect to payments made via the Internet. These types of 
transactions typically involve payments made with respect to loans, insurance 
and utilities. It is predicted that ACH payments will not be widely deployed to 
on-line POS for two reasons. First, an ACH transaction does not provide 
transaction authorization, and secondly, authentication requires a pre-existing 
relationship between the customer and the merchant. Furthermore, ACH 
payments have to be received, deposited and cleared before the funds are 
available. In contrast to ACH transactions, credit and off-line debit cards 
require authorization but not authentication. Similarly, on-line debit requires 
authentication (i.e., a PIN or other authentication). 

Two significant drawbacks with some or all of the above models 
for Internet POS payments are that: 
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1) a pre-existing relationship between the consumer and the merchant must 
exist; and 2) the consumer is required to provide the merchant with his or her 
account and/or PIN. The first drawback of some of the above models cannot 
be practically overcome as it is impossible for a consumer to have pre-existing 
5 relationships with all of the potential merchants conducting business on the 

Internet. With respect to the provision of the consumer's account and PIN 
number over the Internet, even though mail order companies have been 
operating in this manner for years, many consumers feel uneasy about 
electronically providing their account and PIN numbers to strangers over the 
10 Internet. 

Figure 1 depicts the conventional debit/credit transaction model. 
In this model, if the consumer 100 desires to buy a compact disc (CD) from a 
web retailer 100, the consumer 100 electronically transmits its debit or credit 
card number and/or PIN to the web retailer 1 1 0. Upon receipt of this 

1 5 information from the consumer 1 00, the retailer 1 1 0 submits the proposed 

transaction to its bank 120 for approval. The merchant's bank 120 then 
contacts the bank 130 (issuer bank) which issued the debit/credit card to the 
consumer 100. The issuer 130 checks the consumer's balance on the card and 
either approves or rejects the proposed transaction. This approval or denial is 

2 0 transmitted from the issuer bank 1 30 back to the merchant bank 1 20 which 

then informs the web retailer 1 10 of the approval or denial. If the charge to 
the debit/credit card was approved, the transaction is completed by the web 
retailer 1 1 0 shipping the goods to the consumer 1 00. 

The at least one of the drawbacks described above equally 

1 5 applies to electronic bill payment. The first drawback, requiring a pre-existing 
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relationship between the consumer and bill payee is not as great a concern 
because this relationship most likely already exists between the consumer and 
the payee (e.g., the telephone, cable or utility company for example). The 
second drawback which requires the consumer to provide the payee with his or 
5 her account and/or PIN still remains a concern with electronic bill payment. 

Although fraud is less of a problem with respect to bill payment, since the 
consumer presumably has regular dealings with the payee, some consumers 
still view the provision of the payee with at least his/her account number a 
diminution in the consumer's privacy. 

10 

SUMMARY OF THE INVENTION 

In the method of the present invention, a consumer uses its 
Internet software to browse the Internet for goods being offered by various 
Internet merchants. Once the customer finds an item its wishes to purchase, 

15 the consumer's Internet software extracts from the merchant's web site a price 

quote for the proposed purchase along with an identification of the merchant's 
bank and account number. The customer then transmits a payment request 
message to its own bank over the Internet. This payment request message 
simultaneously requests that the consumer's account be debited for the amount 

20 of the price quote and that the payment be made crediting the merchant's 

account at the merchant's bank. If there is sufficient funds in the consumer's 
account, the consumer's bank will return a payment advice digitally over the 
Internet which guarantees the payment. This payment advice is then 
transmitted by the customer's Internet software to the merchant's Internet 

25 server. With guaranteed funding, the merchant can immediately deliver the 
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goods of services to the consumer. In an alternative embodiment, the payment 
advice is transmitted via the Internet directly from the consumer's bank to the 
merchant's Internet server. 

Payment totals for each merchant are settled on a daily basis 
5 using Electronic Funds Transfer via the regional ATM network infrastructure 

with funds being moved from the consumer's account at its bank to the 
merchant's account at its bank. 

By the method of the present invention, both of the significant 
disadvantages of the prior art have been overcome. First of all, the consumer 

10 is no longer providing its confidential financial information to strangers over 

the Internet. Rather, the consumer is dealing directly with its own trusted 
institution, the bank. Furthermore, no pre-existing relationship has to exist 
between the customer and the merchant. The only requirement is that the 
merchant recognize and honor the guaranteed payment from the consumer's 

15 bank. 

The present invention significantly reduces the transactional cost 
as compared to the use of credit cards. The method also provides a reduction 
in fraud and credit losses, while the finality of the transaction virtually 
eliminates dispute and chargeback processing from the viewpoint of the 

20 financial institution. 

The present invention is not limited to the case of a consumer 
making purchases from Internet merchants. The method has further, broader 
applicability by providing the ability for anyone with an account at a financial 
institution to transfer funds to anyone else who also has an account at the same 

25 or a different financial institution. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For the purposes of illustrating the present invention, there is 
shown in the drawings a form which is presently preferred, it being understood 
however, that the invention is not limited to the precise form shown by the 
5 drawing in which: 

Figure 1 illustrates the prior art method of Internet payment 
processing using debit and/or credit cards; 

Figure 2 depicts a first embodiment of the method of the present 

invention; 

1 0 Figure 3 depicts a second embodiment according to the method 

of the present invention; 

Figure 4 illustrates a third embodiment of the method of the 
present invention; 

Figure 5 illustrates additional details of the method of the present 

15 invention; 

Figure 6 illustrates a specific example of the method of Figure. 

4; 

Figure 7 illustrates a specific example of the method of the 
present invention; 

2 0 Figure 8 illustrates a specific example of the method of the 

present invention; 

Figure 9 illustrates a specific example of the method of the 
present invention; 

Figure 10 illustrates a specific example of the method of the 
2 5 present invention; 
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Figure 1 1 illustrates a specific example of the method of the 
present invention: and 

Figure 12 illustrates a specific example of the method of the 
present invention. 

5 

DETAILED DESCRIPTION OF THE INVENTION 

In contrast to the credit card, on-line and off-line debit and other 
payment models existing today, one of the unique features of the method of 
the present invention is the flow of the payment instruction and the payment 

0 which follows. In the credit card, on-line and off-line debit models, a 

consumer provides the merchant with an instruction that authorizes the 
merchant to collect funds from the consumer's bank account. Depending on 
the system, this payment instruction results in a guaranteed customer payment 
in the case of an on-line debit rather than a lengthy wait for funds (such in the 

5 case of a check) or something in between in the case of an off-line debit and 

credit card. The difference between the prior art models and the model of the 
present invention can be described as the difference between a "pull" and a 
"push" model. In the conventional models of today, the merchant "pulls" the 
payment from the consumer's account, while in the present invention the 

) customer "pushes" the payment to the merchant's account. 

Figure 2 illustrates a first embodiment of the method of the 
present invention. Prior to conducting any on-line purchases using the method 
of the present invention, the consumer establishes an Internet payment account 
(IPA) 230 with its bank 220. Once this IPA account 230 has been established, 
the consumer funds this account from its demand deposit account (DDA) 240. 
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The establishment of a separate IPA 230 is preferable from a consumer's point 
of view in order to provide a separate accounting and statement from its 
normal DDA account 240. Furthermore, the IPA account might not be interest 
bearing and the consumer would accordingly only fund small amounts into 
this account in order to cover potential on-line purchases. In an alternative 
embodiment of the present invention, the consumer's payment request for 
credits and debits can be made directly against its DDA account 240. 
Furthermore, the IPA 230 can be funded from a consumer's Line of Credit or 
credit or debit card account held by the bank 220 or any other linked account 
from which the consumer can transfer funds. 

The consumer uses Internet browsing software 200 in order to 
initiate a payment transaction. In one embodiment of the present invention, 
the Internet software is loaded on the consumer's personal computer 201 . In 
alternative embodiments, the software can reside in a web enabled ATM 
machine 202, or remotely located and accessed via a telephone 203. The 
element Other 204 has been illustrated in order to convey that the present 
invention is not limited by any particular physical device and can employ any 
device which provides access to the Internet. For example a public Internet 
kiosk which provides access to the Internet can be used to practice the present 
invention. 

In one embodiment of the present invention, the Internet 
software 200 is used in order to browse the Internet and visit the web sites of 
various merchants. As a consumer browses the web site of a particular 
merchant 210, all of the information viewed by the consumer is downloaded 
onto the consumer's computer or the device which is providing the Internet 



access. This downloaded information includes prices for the goods and 
services offered by the merchant as well as an identification of the merchant's 
bank 250 and the number of an account 260 which the merchant holds at its 
bank 250. If a consumer decides to go ahead with a particular purchase, the 
consumer's Internet software 200 extracts from the downloaded information 
the price for the item and the identification of the merchant's bank 250 and 
account number 260. A transaction identifier is preferably assigned at this 
time either by the merchant's Internet server 2 10 or the consumer's software 
200. 

In another embodiment of the present invention, the entity who 
will eventually be receiving funds from the consumer can be an individual. 
For example, the consumer might be responding to a classified advertisement 
(electronic or traditional paper) or purchasing an item or a sendee through an 
electronic auction site such as eBay(TM). In either of these cases, the 
consumer obtains the payee's bank 250 identification and account number 260 
in a variety of ways. In one method, the consumer obtains this information 
electronically from the service where it contacted the individual (e.g. through 
eBay(TM)). Alternatively, the consumer can obtain the necessary destination 
bank information through offline methods such as the traditional paper 
classified advertisement or through an Email which has been "pushed" to the 
consumer by the potential payee. 

In an alternative bill paying embodiment, the consumer has all of 
the relevant bank and account information for each of the payees (e.g. 
telephone service provider) which the consumer regularly pays bill 
electronically. An electronic bill can be presented to the consumer either 



through E-mail or from an Internet site maintained by the payee or by a 
Consumer Service Provider for the payee. The bill can contain a button for 
paying the bill through the use of the present invention (i.e. through the ATM 
system). When the customer selects the button, a template is presented to the 
customer which has all of the bank and account information prefilled. The 
customer merely fills in the amount he/she wishes to pay. Upon completion, 
the user selects a transmit button in response to which the payment message is 
formatted with the supplied information and transmitted to the consumer's 
bank for processing. The same payment template can be used either included 
in an E-mail or from the payee's web site as described above. 

In a further embodiment, the consumer has a personal 
relationship with the eventual payee and has been previously provided with the 
destination banking information by the eventual payee. For example, if a 
parent has a son or daughter away at college, the parent has knowledge of the 
child's bank 250 and account 260 and is able to transfer funds to the child's 
account 260 in a simple, quick and cost efficient manner by use of the present 
invention. 

Returning to Fig. 2, with the bank 250 identification and account 
260 information in hand, the consumer's Internet software 200 formats and 
transmits a message containing this information to its own bank 220. The 
message will contain at least the identification of the consumer's account 230, 
the destination bank 250, and the destination account 260. For example, this 
payment instruction from the consumer asks that fifty dollars be debited 
against its account #1234 and that credit be forwarded to merchant's account 
#5678 at the merchant's bank. 



With respect to authentication, because the consumer is pushing 
the payment to merchants or other entities or individuals, rather than the 
merchants pulling payments from consumer accounts, the consumers do not 
need to authenticate themselves to the merchant. Rather, the consumers 
authenticate themselves to their own bank 220 which then executes the 
payment to the merchant's account. The consumer's bank 220 will require 
some form of authentication of the payment request from the consumer. This 
authentication can be in the form of a software certification, an encrypted PIN, 
or the mother's maiden name of the consumer. Once the bank 220 has 
authenticated that the message truly originated from the consumer, the bank 
220 can then fulfill the payment request. 

This method of the present invention is quite attractive to 
consumers because they can pay any individual or entity regardless of the 
existence of a pre-existing relationship with that individual or entity. The 
transaction can furthermore be conducted from anywhere there is access to the 
Internet. The IPA account 230 can be used and managed through the 
consumer's PC 201, a web enabled ATM 202, by phone 203 or by any other 
web enabled device 204. With respect to merchants, individuals or other 
entities which are paid by the method of the present invention, there are 
several advantages. This method opens up a universe of buyers/payors 
without the access or desire to use credit or debit cards online. A very low 
effort is required on the part of a merchant which only has to publish its bank 
250 and IPA deposit only account 260 information on its web site. If a 
merchant has been using traditional credit card methods, the present invention 
provides the merchant with significant savings in credit card processing, fraud 
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loss, and chargeback costs. The present invention also provides the ability to 
economically accept micropayments. 

Returning again to Fig. 2, in fulfilling the payment request from 
the consumer, the bank 220 will initially verify that there are sufficient funds 
in the consumer's IPA account 230 to satisfy the payment request. If there are 
sufficient funds in the consumer's IPA account 230, the account is 
immediately debited or the funds held such that funds equal to the amount of 
the payment are no longer available in the customer's IPA account 230. The 
funds debited from the consumer's IPA account 230 are credited to the 
destination account 260 as described in more detail below. If insufficient 
funds exist in the customer's IPA account 230, the payment request is denied 
and the consumer's Internet software 200 is informed of the insufficient funds 
condition. In an alternative embodiment of the present invention, the 
consumer is provided with the ability to transfer funds from its DDA account 
240 into the IPA account 230 such that sufficient funds are available to cover 
the payment request. 

If sufficient funds exist in the IPA account 230 to process the 
payment request, the consumer's bank 220 generates a digital payment advice 
which is transferred back over the Internet to the consumer's Internet software 
200. In a preferred embodiment, this payment advice is digitally signed by the 
consumer's bank 220, thus guaranteeing the payment. Once this payment has 
been digitally signed by the consumer's bank 220, all of the risk associated 
with this payment lies with the consumer's bank 220 and not with the merchant 
210 or its bank 250 as with some of the models described above. For this 
reason, the model of the present invention is an attractive alternative to 



- 13- 



merchants conducting business on the Internet. Various forms of 
implementing the digital signature by the consumer's bank 220 are well known 
in the art. 

Upon receipt of the payment advice from the consumer's bank 
220, the consumer's Internet software 200 forwards this payment advice to the 
merchant's Internet server 210. Once the merchant has received the payment 
advice from the consumer's Internet software 220, the transaction can be 
completed by the shipment of the goods or provision of the service to the 
consumer. 

The settlement process between the consumer's bank 220 and the 
merchant's bank 250 typically occurs once a day, at the end of the day, but 
may occur in real time or batched processed when the transactions reaches a 
dollar or absolute number limit. As described above, the consumer's IPA 
account 230 has been debited for the amount of the purchase. This debited 
amount now needs to be transferred to the merchant's bank 250 in order that a 
credit be applied to the merchant's account 260. In a preferred embodiment of 
the present invention, the merchant has established a deposit only IPA 260 in 
which funds can only be deposited and not withdrawn. This is a security 
feature which protects the merchant from various forms of electronic fraud. 
Alternatively, the destination account 260 could be another type of deposit 
only account or a DDA account in the case where the receiving party truly 
trusts the consumer (e.g. the parent/child relationship previously described). 

In the present invention, the consumer's bank 220 accomplishes 
the payment settlement via the conventional ATM electronic Funds Transfer 
process. Using this well known process, the consumer's bank 220 designates 
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the merchant's bank 250 and the specific account 260 to which the credit of the 
purchased amount should be applied. Furthermore, the consumer's bank can 
include in the ATM message the transaction ID previously described for 
tracking and auditing purposes by the merchant and the merchant's bank 250. 
This auditing information allows the merchant to match the merchant's 
payables to its receipts. This information can also be used in the reconciliation 
process with respect to the merchant's account. 

Periodically, funds from the merchant's deposit only IPA 
account 260 are transferred (swept) by the merchant bank 250 into the 
merchant's conventional DDA account 270. 

Figure 3 illustrates an alternative embodiment of the present 
invention. All of the initial steps with respect to the consumer browsing the 
merchant's web site and formulating the payment request which is forwarded 
to its bank 220 are the same as illustrated in Figure 2. The difference in the 
embodiment illustrated in Figure 3 as compared with the embodiment depicted 
in Figure 2 is that the payment advice from the consumer's bank 220 is 
forwarded directly to the merchant's Internet server 210. This payment advice 
will therefore come from a separate Internet Protocol (IP) address from the 
address that connects the consumer's Internet software 200 to the merchant's 
Internet server 210. This feature will provide additional confidence to the 
merchant that the advice has indeed originated from the consumer's bank and 
is not a fraudulently generate advice. 

The push model of the present invention has significant 
advantages over the conventional methods used today. This method is 
extremely easy for online banking customers to adopt. The method guarantees 



payment to the merchant without any concerns about repudiation inherent in 
the use of a credit card. The present invention reduces fraud loses compared 
to offline debit, credit card or checks. The method allows consumers to 
conduct online shopping without having to provide any personal confidential 
financial information to unknown merchants. The method allows consumers 
to conduct these financial transactions solely with its own financial institution. 

Fig. 4 illustrates the broader embodiment of the present 
invention briefly described above. In this embodiment, a customer 1 (payor) 
of a financial institution is able to transfer funds to a customer 2 (payee) of a 
the same or different financial institution. This embodiment is particularly 
suitable for the bill payment example described above. Prior to the practice of 
the method illustrated in Fig. 4, both customer 1 (payor) and customer 2 
(payee), must each have established an account and deposited funds into their 
respective financial institutions. In a preferred embodiment, these accounts 
are specific Internet Payment Accounts (IPA) II and 12, at the customers' 
respective banks Bl and B2 (Fig. 5). Here, customer 1 has deposited SI 000 
into IPA II and customer 2 has deposited $200 into IPA 12. As previously 
described, an IPA can be funded through any linked account such as the 
customer's DDA or credit account, or through another IPA. The customer 
does not need to have a DDA or credit account at a bank to set up an IPA, as 
these accounts could be funded by accounts at another bank or through cash. 
As shown in Fig. 5, however, both customer 1 and customer 2 have linked 
DDA accounts Dl and D2, respectively, to IPA II and IPA 12. Once this is 
done, the IPAs can be used for web shopping, pay anyone anywhere, and bill 
payment. Alternatively, as described above, the payments made according to 
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the method of the present invention can be made directly from/to a DDA 
account. 

Once customer 1 has set up its IPA II, the customer 1 can 
request that payments be made (e.g. bills) through the IPA II . With this 
payment system, customer 2, the payment recipient, can be a billing company, 
such as a telephone company. As previously described with respect to Fig. 3, 
in step 400, the payment can be requested by phone, ATM or PC. Customer 1 
must give his/her bank, Bl , the following information: the payment amount, 
customer 2's BIN and IPA#. In step 410, this information is used by bank Bl 
to create a transaction instruction filed under a transaction ID#, Tl. Because 
customer 1 is directly contacting his/her own bank Bl, no authorization is 
required. Customer 1 authenticates him/herself by inputting a pin number or 
other ID. In step 420, after authentication, customer l's bank, Bl, debits 
customer l's IPA, II , by the amount of the payment (e.g. $100 as illustrated in 
Fig. 4). In step 430, the transaction instruction representing the credit to 
customer 2 is transmitted to customer 2's bank B2 through the ATM network. 
The receiving bank B2 can send a confirmation message back to customer 1 
through its bank Bl that the transaction was received by bank B2. 

In step 440, upon its receipt by the bank B2, the transaction 
information Tl representing the credit to customer 2's account, is stored in a 
personal virtual lockbox. Alternatively, the credit is directly applied to 
customer 2's IPA 12. The concept of a personal virtual lockbox is borrowed 
from retail lockbox processing in which a bank collects the receivables for an 
entity and performs the financial processing on such receivables. The personal 
virtual lockbox in the present invention operates similarly in that it stores 
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receivables throughout the day for customer 2 which are then swept, in step 
450, into the customer's IPA 12. In step 460 the actual credit is applied to 
customer 2's IPA 12. 

Reference is now made to Fig. 6 which illustrates a further 
example of the present invention. Fig. 6 illustrates a specific application of the 
present invention in which a customer 1 desires to transfer funds to customer 
2, where customer 2 is anyone that needs to be paid, such as one's gardener, or 
anyone who requires funds, such as a child at college. As with the example of 
Fig. 4, customer 1 and customer 2 preferably have established and deposited 
funds into Internet payment accounts IPA II and IPA 12 at the customer's 
respective banks Bl and B2 (Fig. 5). Customer 1, for example the owner of 
real property, has deposited $1000 into IPA II and customer 2, for example a 
gardener, has deposited $200 into IPA 12. 

Although not necessary, customer 1 and customer 2 have 
established DDA accounts Dl, D2, respectively, at their banks Bl, B2 to link 
with the IPA accounts. 

At step 600, customer 1 requests that a payment be made, for 
example by phone, ATM, PC, etc. In this instance, customer 1 wishes to 
transfer $100 from his IPA account II in bank Bl to customer 2's IPA account 
12 at bank B2. At step 610, customer 1 provides his payment account number, 
customer 2's BIN number and customer 2's IPA account number. This 
produces a transaction instruction for a particular transaction, here designated 
ID# 1, where the BIN number is designated B2 and the IPA number is 
designated 12. Customer 1 authenticates himself by inputting a pin number or 
other such ID number into the system. 
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At step 620, bank Bl debits customer l's IPA II by $100, 
leaving IPA II with a balance of $900. At step 630, the transaction instruction 
is transmitted to bank B2 through the ATM switch network. 

At step 640, the transaction instruction commanding a deposit 
into customer 2's IPA account 12 is stored in a personal virtual lockbox. As 
previously discussed, the credit to customer 2's IPA account 12 may 
alternatively be directly applied rather than utilizing the virtual lockbox. The 
credit of $100 is applied to customer 2's IPA 12 when accounts are swept in. 
At step 650, customer 2 actually receives the $100 credit to his account and is 
provided with a bill payment message indicating that the transaction was 
completed. 

Those skilled in the art will appreciate that the above example 
applies equally well to the situation in which customer 1 would wish to 
transfer funds to, for example, a child at college, rather than providing funds in 
exchange for services. 

The following sections will describe five different specific 
embodiments of the present invention with respect to Figures 7-12. 
Product Definition: 

The Global Internet Pay Anyone account is a safe, sound, and 
secure electronic payment system which will allow consumers and merchants 
to shop on the web, pay bills, and pay anyone virtually anywhere. Through the 
use of Internet technology married to an existing payment infrastructure, 
consumers and merchants alike will find that Internet Pay Anyone (IPA) 
accounts are both efficient and convenient, while offering the highest levels of 
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security. The following document illustrates how five different transaction 
types would flow through this payment system. 

IPA accounts are available to both consumers and merchants. By 
furnishing both payors and payees with IPA's, banks can validate the identities 
of both parties. In addition, all payment messages are 128 bit SSL encrypted. 
This coupling of authentication and encryption provide consumers and 
merchants with the comfort that their transactions are secure and private. The 
IPA enriches the consumer e-commerce experience by eliminating the tedious 
process of filling out lengthy payment and shipping fields- this is done 
automatically. Merchants will also benefit from the above features, as research 
indicates that most e-commerce purchases are abandoned at the point of sale 
due to consumers' unwillingness to complete lengthy forms or provide 
personal credit card numbers. Once a transaction is authorized on the web, it is 
then passed through the existing ATM infrastructure. 
Product Components: 

The enabling functionality resides in two pieces: a consumer 
"Wallet" and a merchant "Virtual Private Lockbox" (VPL). The Wallet and 
VPL is software that, when installed, augments any Internet browser with e- 
commerce capability. The software sits in front of (and links to) an IPA 
account. This account is a special purpose DDA with limited functionality. 

The Wallet: Consumers access their IPA's via their Wallet, 
which is accessible through their Internet browser. Consumers use this Wallet 
to fond their account, shop on the web, pay bills, pay anyone else with an IPA, 
receive funds from any IPA owner, and check their recent Wallet activity. The 
Wallet sits in front of their IPA account, which is a limited purpose DDA 
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account that sends transactions over the ATM network. The Wallet provides 
consumers with a safe, secure, and convenient way to conduct financial 
transactions over the web. 

The VPL: Merchants access their IPA's via their VPL which, 
like a Wallet, is accessible through any Internet browser. The VPL securely 
receives all payments via the ATM network. Once a day, these funds can be 
automatically swept from their IPA to their DDA account. In addition, the 
VPL supplies merchants with value-added services. The VPL provides online, 
real-time transaction reports, which reconcile accounts receivable/purchase 
records against payment records. All transactions are archived and retrievable 
via the VPL's payment search engine, so that merchants will have powerful 
data mining and customer service tools at their fingertips. These features make 
the VPL the perfect vehicle for order fulfillment and record keeping. 

With respect to Figure 7, Initiating/Funding the Wallet - The 
Internet Pay Anyone (IPA) account is accessed through a virtual Wallet. This 
Wallet can be accessed via the Internet, ATM, telephone, Kiosk, and even a 
personal digital assistant. The primary method for funding the Wallet is 
through the Wallet owner's DDA, credit, and savings accounts, which can be 
linked to the Wallet through Online Banking. Alternative funding options are 
by an externally sponsored credit card, by check or money order, or through 
the ACH network. 



Step# 


Description 




Installing the Wallet 


1 


User signs on to Online Banking via PC. Site is 128-bit SSL 
encrypted, and user is authenticated 
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2 


Once logged on, user selects Wallet option from main menu. 
There are two options: 

• Install a web Wallet 

• Move funds to/from Wallet 


3 


User selects "Install a web Wallet". Screen instructs user that weh 

' ' * k^vi vvu null uvlkj u Jvl vXICIL VV 

Wallet will now be installed as a button on the browser toolbar. 
Once installed, user is prompted to provide some background 
information that will assist in web purchases and payments: 
examples include: shipping name, shipping address, and other 
optional information. 




Funding the Wallet 


4 


The primary method for initial and future funding of Wallet is 
performed through a link between the Wallet and Online Banking. 
For initial funding of the Wallet, the user will select "move funds 
to/from Wallet" from online banking menu. User selects "move 
funds to Wallet", and provides the following: 




• Source of funds- checking, credit card, savings, etc. 

• $ amount • funding date 

• one time or repeat 

Upon completion of above, the Wallet is funded (subsequent 
funding of the Wallet can be done via both the Wallet or directly 
within Online Banking). 


5 


In addition to funding via online banking, instructions can be 
given for funding via phone, ATM, kiosk, or PDA. 




Funding the Wallet from an external credit or debit card, or DDA 
account 


6 


For accounts not linked to online banking, user selects "fund with 
a non-[my bank] account". User selects the financial merchant 
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(AMEX, VISA, etc.) and keys in account number, expiration (if 
applic), and $ amount, and a funding request is transmitted to 
merchant acquirer (this account info will be stored for future 
funding requests) 


7 


Merchant Acquirer (.such as Chase Merchant Svcs) authonzes the 
transaction and passes the request through the EFT switch. 


8 


Financial merchant receives funding request via bt 1 switch, and 
verifies card number, expiration, and credit limit. 


9 


Funding is authorized by financial merchant 


10 


Funding is received by Wallet, which is an IPA (Internet Pay 
Anyone) account. 


11 


Funds are settled once a day between credit card's bank and 
user's bank's IPA 


Note: 


Other alternatives sources for Wallet funding are check, money 
order, or ACH 



Model #1 

With respect to Figure 8, Web Shopping: The Wallet and the Virtual 
Private Lockbox (VPL) significantly enhances the consumer and merchant 
experience when used for web shopping. A Wallet icon will be located on the 
browser toolbar. When shopping the web, the user simply launches the Wallet. 
Once the consumer commits to purchasing an item, the merchant's site will 
recognize that the transaction is from a Wallet owner. The Wallet will 
instantly fill out all required fields. In addition, rather than the merchant 
"pulling" in the consumers account information, the Wallet "pushes" 
guaranteed funds to the merchant's Virtual Private Lockbox, without the 
merchant obtaining the consumers account info. This transaction is virtually 
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instantaneous, provides privacy, security, and convenience to the consumer - 
and guarantees funding, provides reconcilement, and supplies archival records 
to the merchant. 



Step# 


Description 


1 


User launches browser and selects Wallet icon from browser 
toolbar. 


2 


User keys in IPA (Internet Pay Anyone) # and password. The user 
is authenticated and has access tn their Wallpt 


3 


User is then presented with balance information and can select 
from several options: 


4 


User selects "Shop on the Web". Browser could be initially 
directed to ChaseShop.com for a list of chase-approved 
merchants, however user is free to navigate to the merchant web 
site of their choice. 


5" 


User selects item for purchase from merchant web site. Since web 
Wallet is active, merchant recognizes user as a Wallet customer, 
and purchase fields (shipping address, name, etc.) are auto- 
populated from Wallet. 


6 


Merchant site generates and transmits to user a bill payment 
message providing the following data; 

Merchant BIN 

Merchant Account # 

Transaction ID 

$ Amount 


7 


Bill Payment message is transmitted back to Wallet window. User 
reviews bill payment message and selects "purchase item". 



8 


Wallet verifies balance and passes transaction to IPA account; 
payment conformation sent to the Merchant's website. 


9 


Bill payment message is passed from user's bank's IPA to the 
merchant's DDA via the ATM switch. 


10 


The bill payment record is transmitted from the merchant's DDA 
tn the merchant's Virtual Private Lockbox (VPL). 


11 


Upon receipt of these guaranteed funds, merchant's payment 
rppnrH ran hp reconciled against the merchant's Durchase records. 
With VPL, Merchant has a product that allows for secure 
transaction fulfillment, reconcilement ability, record-keeping and 
archive possibilities. 


12 


Merchant ships goods 


13 


Funds are settled once a day between user's bank's DDA and 
merchant's bank's DDA. 


14 


Funds can be swept to merchant's cash concentration bank. 


15 


DDA could also be swept to a host account 



Model #2 

With respect to Figure 9, Pay Anyone: The Wallet provides the user 
with tremendous flexibility. Anyone with a Wallet can send funds to anyone 
else with a Wallet. This funds transfer is instantaneous and at no cost to the 
consumer, and is conducted in a secure environment. 



Step# 


Description 


1 


User launches browser and selects Wallet icon from browser 
toolbar. 


2 


User keys in IPA (Internet Pay Anyone) # and password. The user 
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is authenticated and has access to their Wallet. 


z U 




User is then presented with balance information and can select 






from several options: 




4 


User selects "Pay Anyone". User is given several options in the 






Pay Anyone menu screen: 






• Manually key in payee's IPA # 






• Select a prior payee from a drop down menu 






Aad/Kemove/bdit Payee irom drop down menu 


M 
r. s 




User keys in (or selects) payee's IPA #, $ amount, and a 


t" 




description (optional). This payee IPA will be linked to either a 






Wallet or a VPL, depending on whether the payee is a consumer 






or a merchant. 


Q 


5 


Payment info, is transmitted to payee's Wallet for IPA # 


ru 




verification as well authorization to pay. 




6 


Wallet con tlTTDS that information ic mrrpri <*r\A tr^ncmifc o 






payment message witn tne following data: 






• Payee BIN 






■ Payee Account # 






• Transaction ID 






• $ Amount 






• description 




7 


User reviews payment message and selects "OK to Pay" 


25 


8 


Wallet sends transaction to IPA account; an expected payment 






record is also transmitted to the payee's Wallet or VPL. 




9 


Payment message is passed from user's bank's IPA to the payee's 






DDA via the ATM switch. 
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10 


The payment record is transmitted from the payee's DDA to the 
payee's IP A/Wallet 


11 


Upon receipt of these guaranteed funds, payee's payment record 
is reconciled against the expected record. 


12 


Payee now has immediate use of funds. These funds can be used 
for web shopping, bill payment, pay anyone, or withdrawal via an 
ATM. If the Payee Wallet or VPL owner does not have access to 
a PC, they can still utilize their funds through conventional 
banking methods (by visiting a branch, through the phone, or at 
any store that carries a credit or debit card reader, using their IPA 
# and password). 


13 


Funds are settled once a day between user's bank's DDA and 
payee's bank's DDA. 



Model #3A 

With respect to Figure 10, Bill Payment-Direct: There are three 
different bill payment methods described in this document. The first method is 
the direct model. In this model a biller establishes an e-billing capability on its 
own web site. Once enrolled in the service, the customer will receive an e-mail 
notification that a bill is available for payment at the toiler's web site. The 
customer will launch the Wallet from the browser and then access the biller's 
web site. A payment will then be transmitted from the Wallet to the biller's 
Virtual Private Lockbox. As in the other models, the transaction is secure, 
protects the customer's privacy, and provides the biller with guaranteed 
funding, reconcilement, and archival records. 
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Step# 


Description 




Establishing e-billing relationshiD 


1 


Merchant advertises e-billing service via e-mail, mail, or 
web. 


2 


User enrolls in e-bill service at biller's web site. After 
enrollment, user will receive monthly email notification 
when bills are available. 




Using the Wallet 


3 


User launches browser and selects Wallet icon from 
browser toolbar. User keys in IPA # and password. The 
user is authenticated and has access to their Wallet. 


4 


User is then presented with balance information and can 
select from several options: 




User selects "Pay Bills". User is given several options in 
the Pav Bills menu screen - 
• Pay Bills 

■ Edit Billing information 

User selects "pay bills" and navigates to biller's web site 
(Wallet will already contain user's billing info) 


5 


Since web Wallet is active, biller's website recognizes 
user as a Wallet customer. In addition, biller's website 
verifies that customer has an established e-billing 
relationship. 


6 


Biller site generates and transmits to user a bill payment 
message providing the following data: 
■ Biller's BIN 
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• Biller's Account # 

• Transaction ID 

J) rVIllUUIll 


7 


Bill Payment message is transmitted back to Wallet 
wiiiuuw. Uaci leviewb uni payment ineobagc aiiu i>ciccio 

"pay bill". 


Q 
0 


waiiei venues oaiance ana passes transaction to ir/\ 
account; payment conformation sent to the Biller's 
website. 


9 


Bill payment message is passed from user's bank's IPA to 
the biller's DDA via the ATM switch. 


10 


The bill payment record is transmitted from the biller's 
DDA to the biller's VPL (virtual private lockbox). 


11 


Upon receipt of these guaranteed funds, biller's payment 
recoru is reconciled dgdinsi tne Diner s accounts 
receivable files. With VPL, Merchant has a product that 
allows for secure transaction fulfillment, reconcilement 
ability, record-keeping and archive possibilities. 


12 


Funds are settled once a day between user's bank's DDA 
and biller's bank's DDA. 


13 


Funds can be swept to biller's cash concentration bank. 



20 Model #3B 

With respect to Figure 11, Bill Payment- Service Provider 
Consolidation: The second bill payment method is similar to the first, however 
in this model a central service provider consolidates e-bills from different 
billers, so that the customer has a single web site for reviewing bills and 
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making payments. The service provider can be seamlessly outfitted with 
archival capability, so that customers can review their bill payment history. 
The Wallet provides the consumer with privacy, security and convenience. 
The Virtual Private Lockbox provides Merchants receiving payments through 
this web site guaranteed funding, reconcilement and archival records. 





Step# 


Description 


- 




Establishing e-billing relationship 


pt~ 


1 


Customer Service Provider (CSP) advertises e-billing service via 






e-mail, mail, or web. 


^ 10 


7 

L 


user enrolls in e-bill service at CSP s web site, and selects which 






oiiis it wisnes to receive. After enrollment, user will receive 






monthly email notification when bills are available 






Usin? the Wallet 


U 


3 


User launches browser and selects Wallet icon from browser 


fU 




toolbar. User keys in IPA (Internet Pay Anyone) # and password. 






The user is authenticated and has access to their Wallet 




4 


User is then presented with balance information and can select 






from several options: 






User selects "Pay Bills". User is given several options in the Pay 






Bills menu screen: 






• Pay Bills 






• Edit Billing information 






• Review Billing History 






User selects "pay bills" and navigates to CSP's 


15 


5 


Since web Wallet is active, CSP's website recognizes user as a 






Wallet customer. In addition, CSP's website verifies that 






customer has an established e-billing relationship. 



00425753 1 



-30- 



6 


User selects which bills to nav and kevs in *s amount f\P site 
generates and transmits to user a bill payment message 
providing: 


7 


Bill Payment message is transmitted back to Wallet window. 
User reviews bill payment message and selects "pay bill". 


8 


Wallet verifies balance and passes transaction to IPA account; 
bill payment expected record is transmitted to the CSP's website. 


9 


Bill payment message is passed from user's bank's IPA to the 
CSP's DDA via the ATM switch. 


10 


The bill payment record is transmitted from the CSP's DDA to 
the CSP's VPL (virtual private lockbox). 


11 


Upon receipt of these guaranteed funds, CSP's payment record is 

rppnnPilprl ^QAiriQt thp f^P'c ppprmntc rAPPivcihlp flip \A/ith \/T*T 
iv^v/Uuviivu a^aiiiM mc v^or i> avVUUlllo ivvvlVaUlC IJJC VVIUI V r JLf> 

Merchant has a product that allows for secure transaction 
fulfillment, reconcilement ability, record-keeping and archive 
possibilities. 


12 


Funds are settled once a day between user's bank's DDA and 
billers' bank's DDA. 


13 


Fluids ran hp <sWPnt tn hillpr'Q pach pnnppntrahnn hanV 

X UliUO VUli OWVJJL LVJ Ulll^/L O VUOll UUllvy villi uUUli UCUllY» 


14 


Note: Multiple record keeping models can be supported. The 
billers can push billing info, directly to the CSP's web site, or 
alternatively, bills can be channeled to the CSP via Spectrum. 


15 


Note: CSP can be outfitted with an archive to store transaction 
history as well as a customer service unit to resolve transaction 
inquiries. 
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Model #3C 

With respect to Figure 12, Bill Payment- Customer Consolidation: In 
the third bill payment method, the e-bills are delivered directly to the customer 
in the form of an e-mail. Each e-bill contains a hotlink, which directs the 
customer to the biller's web site. When the customer activates the Wallet, the 
web site recognizes the Wallet customer and initiates a payment message. The 
customer can then push the payment to the biller in the same manner that a 
payment is pushed in the web model, pay anyone model, and two other bill 
models. As in the two previous models, the merchant receives the guaranteed 
funding, reconcilement, and archival records benefits of the Virtual Private 
Lockbox product. 



Step# 


Description 




Establishing e-bilhng relationship 


1 


Biller advertises e-billmg sendee via e-mail, mail or web 


2 


User enrolls m e-bill service by clicking on "sign me up!" hotlink 
in email, which launches browser and auto-directs user to biller's 
web site. After enrollment, user will receive bills directly in their 
email box. 




Using the Wallet 


3 


User logs on to email and receives an e-bill. User clicks on 
payment hotlink in email, which launches browser and auto- 
directs user to billers web site. User selects Wallet icon from 
browser toolbar. User keys in IPA (Internet Pay Anyone) # and 
password. The user is authenticated and has access to their 
Wallet. 


4 


Since web Wallet is active, biller's website recognizes user as a 
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Wallet customer. In addition, biller's website verifies that 
customer has an established e-billing relationship. 


5 


User keys in $ amount to pay. Biller's site generates and 
transmits to user a bill payment message providing the following 
data: 

• Biller's BIN 

• Biller's Account # 

1 laJlaaLtlUTl LU 

- $ Amount 


0 


uiu raymcni message is Transmiueu uacK to waiiei window. 
User reviews bill payment message and selects "pay bill". 


7 

1 


Waiiei venues udiance ana passes Transaction to ir/\ account, a 
bill payment expected record is transmitted to the Biller's 
website 


8 


Bill payment message is passed from user's bank's IPA to the 
biller's DDA via the ATM switch. 


9 


The bill payment record is transmitted from the biller's DDA to 
the biller's VPL (virtual private lockbox). 


10 


Upon receipt of these guaranteed funds, biller's payment record 

iq rprnrinlpff £*dPHTi<:t thp hillpr's; arrnnnk tpppivjiHIp flip AA/ifh 

VPL, Merchant has a product that allows for secure transaction 
fulfillment, reconcilement ability, record-keeping and archive 
possibilities. 


11 


Funds are settled once a day between user's bank's DDA and 
billers' bank's DDA. 


12 


Funds can be swept to biller's cash concentration bank. 
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Although the present invention has been described in relation to 
particular embodiments thereof, many other variations and other uses will be 
apparent to those skilled in the art. It is preferred, therefore, that the present 
invention be limited not by the specific disclosure herein, but only by the gist 
and scope of the disclosure. 
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We claim: 

1 . A method for effectuating an electronic payment between a payor 
and a payee, the payor having a payor account at a payor bank and the payee 
having a payee account at a payee bank, the method comprising the steps of: 

generating a payment request identifying the payee bank, the payee 
5 account and an amount of the payment; 

transmitting the payment request to the payor bank; 
debiting the payor account by the amount of the payment; 
transmitting a transaction instruction representing a credit in the amount 
of the payment from the payor bank, through an Automated Teller Machine 
1 0 (ATM) system to the payee bank; and 

crediting the payee account in the amount of the payment in response to 
the receipt of the transaction instruction. 

2. The method as recited in claim 1, further comprising the step of 
retrieving payee information that identifies the payee bank and the payee 
account. 

3. The method as recited in claim 2, wherein the retrieving step further 
comprises the step of retrieving the payee information from an Internet web 
site. 

4. The method as recited in claim 3, wherein the retrieving step is 
automatic. 
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5. The method as recited in claim 1, wherein the step of transmitting 
the payment request to the payor bank further comprises the step of 
transmitting the payment request through the Internet. 

6. The method as recited in claim 5, wherein the step of transmitting 
the payment request to the payor bank is accomplished by using a personal 
computer. 

7. The method as recited in claim 5, wherein the step of transmitting 
the payment request to the payor bank is accomplished by using am Internet 
enabled ATM machine. 

8. The method as recited in claim 1, wherein the step of transmitting 
the payment request to the payor bank further comprises the step of 
transmitting the payment' request by telephone. 

9. The method as recited in claim 1, further comprising the step of 
transmitting a guarantee of the payment from the payor bank to the payee. 

10. The method as recited in claim 9, wherein the transmittal of the 
guarantee is directly to the payee. 

1 1 . The method as recited in claim 9, wherein the transmittal of the 
guarantee is from the payor bank to the payor to the payee. 
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12. The method as recited in claim 9, further comprising the step of the 
payor bank digitally signing the guarantee. 

13. The method as recited in claim 1 , wherein the payee account is a 
deposit only account. 

14. The method as recited in claim 1, wherein the payee is a billing 
company, the payor is a customer of the billing company and the payment is in 
response to a bill from the billing company. 

15. The method as recited in claim 14, further comprising the step of 
• receiving the bill electronically. 

16. The method as recited in claim 1 5, wherein bill is electronically 
received via E-mail. 

17. The method as recited in claim 15, wherein bill is electronically 
received from an Internet site. 

18. The method as recited in claim 14, further comprising the step of 
receiving a template containing at least information identifying the payee bank 
and payee account . 

19. The method as recited in claim 18, further comprising the steps of: 
inserting into the template the amount of the payment; and 
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generating the payment request in response to the information 
contained in the template . 

20. A method for effectuating electronic payments for online purchases 
made by a consumer from a merchant, the method comprising the steps of: 

retrieving from an Internet site of the merchant a purchase amount and 
merchant information identifying a merchant's financial institution and a 
merchant's account; 

forming a payment request including the purchase amount and the 
merchant information; 

transmitting the payment request to a financial institution at which the 
consumer maintains an account; 

debiting the consumer's account by the purchase amount; 

generating a payment instruction for crediting the merchant's account 
by the purchase amount 

transmitting the payment instruction to the merchant's financial 
institution through an Automated Teller Machine (ATM); and 
crediting the merchant's account by the purchase amount. 

21. The method as recited in claim 20, wherein the retrieving step is 
automatic. 



22. The method as recited in claim 20, wherein the step of transmitting 
the payment request to the consumer's financial institution further comprises 
the step of transmitting the payment request through the Internet. 
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23. The method as recited in claim 22, wherein the step of transmitting 
the payment request to the consumers^ financial institution is accomplished by 
using a personal computer. 

24. The method as recited in claim 22, wherein the step of transmitting 
the payment request to the consumer's financial institution is accomplished by 
using am Internet enabled ATM machine. 

25. The method as recited in claim 20, wherein the step of transmitting 
the payment request to the consumer's financial institution further comprises 
the step of transmitting the payment request by telephone. 

26. The method as recited in claim 20, further comprising the steps of: 
generating a payment advice guaranteeing the payment amount will be 

credited to the merchant's account; and 

transmitting the payment advice to the merchant. 

27. The method as recited in claim 26, wherein the transmittal of the 
guarantee is directly to the merchant. 

28. The method as recited in claim 27, wherein the transmittal of the 
guarantee is made using a different Internet Protocol (IP) address from the IP 
address used by the consumer to view the merchant's Internet site. 
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29. The method as recited in claim 26, wherein the transmittal of the 
guarantee is from the consumer's financial institution to the consumer to the 
merchant. 

30. The method as recited in claim 26, further comprising the step of 
the payor bank digitally signing the guarantee. 

31. The method as recited in claim 20, wherein the merchant's account 
is a deposit only account. 

32. The method as recited in claim 20, wherein the consumer's account 
is a demand deposit account. 

33. The method as recited in claim 20, wherein the consumer's account 
is an account only used for making payments using the method of the present 
invention. 

34. The method as recited in claim 20, wherein the consumer's account 
is funded from a different account maintained by the consumer. 

35. The method as recited in claim 34, wherein the different account is 
a demand deposit account. 
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ABSTRACT OF THE INVENTION 

A method for effectuating electronic payments more specifically for 
making electronic payments for Internet purchases. Upon finding an item 
which it wishes to purchase on an Internet retailer's web site, a consumer using 
its Internet software extracts from the web site a price quote for the proposed 
purchase along with an identification of the merchant's bank and account 
number. The customer transmits a payment request message to its own bank 
over the Internet. This payment request message simultaneously requests that 
the consumer's account be debited for the amount of the price quote and that 
the payment be made crediting the merchants account at the merchants bank. 
The consumer's bank generates a payment advice that guarantees the payment. 
The payment advice is transmitted to the merchant. With guaranteed funding, 
the merchant can immediately deliver the goods of services to the consumer. 
The customer's bank credits the merchant's account using the regional ATM 
network infrastructure. 
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